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3.  ELEMENT  DEFINITION  PHASE 

In  the  Element  Definition  Phase  each  Element  performs  the  engineering  analysis 
necessary  to  implement  the  allocated  system  requirements  and  specify  the  functional 
design.  This  effort  leads  to  the  development  of  Element  computer  prograrn  performance 
requirements,  detailed  interface  requirements,  associated  design-level  disclosure,  and 
rationale. 

The  Elements  develop  the  required  PPS  SCs  and  ICRs  to  implement  the  system 
requirements.  They  perform  the  design  requirements  analysis  and  identify  any  necessary 
changes  to  the  PIDS  SCs.  They  modify  program  design  documentation  to  reflect  program 
design  approach  and  the  computing  system  components  and  architecture.  Data  and 
control  flows  and  analysis  requirements  are  documented  In  the  Element  functional 
development  folders  (PDFs). 

Each  Element  prepares  preliminary  ICRs^  and  routes  them  for  approval  by  the  Element 
Change  Control  Board  (ECCB),  System  Engineering,  AWS  CRB,  and  the  NSWCDD  Mk 
7  Interface  Control  Working  Group  (ICWG)  or  the  PMS400  non-Mk  7  ICWG.  The  Element 
also  prepares  preliminary  PPS  SCs  and  the  associated  film  label  change  requests  (FLCRs) 
and  CPCRs  and  routes  them  for  approval  by  the  ECCB  and  the  AWS  CRB. 

Each  Element  evaluates  the  PPS  SCs  and  the  ICRs  and  updates  its  Element 
development  plan,  which  includes  a  functional  build  definition,  a  description  of  resource 
impacts,  an  element  development  schedule,  preliminary  ACC  and  ACSC  site  requirements, 
and  a  risk  management  plan.  The  Elements,  System  Engineering,  ST&E,^  and  ATC 
conduct  an  analysis  of  requirements  and  update  the  specific  simulator  and  simulation 
performance  requirements.  ST&E  performs  engineering  analysis  based  on  system 
changes  and  Element  test  concepts  and  initiates  system  test  planning.  Systems 
Simulation,  in  consultation  with  System  Engineering,  Elements,  and  ATC,  identifies  crew 
training  requirements  and- changes  to  AEGIS  Combat  Training  System  (ACTS)  and 
Computer-Aided  Submode  Training  (CAST)  lessons.  Baseline  Management  conducts  a 
review  of  the  test  planning  and  training  requirements  and  updates  the  baseline 
management  plan. 

Preliminary  Design  Review  (PDR)  packages  are  developed  and  reviewed  by  the 
Elements.  The  PDR  packages  are  presented  to  the  AWS  CRB  for  approval  and  then 
distributed  to  NSWCDD  Organizations  for  review  and  preparation  of  technical  comments. 
ERTs  and  an  SRT  are  formed  to  direct  and  coordinate  the  review  of  the  PDR  package. 
ERTs  review,  categorize,  and  adjudicate  all  comments.  The  SRT  reviews  the  categorized 
comments,  preliminary  system  test  planning,  and  crew  training  requirements  and 
adjudicates  all  problems. 


'ICRs  are  c»nsiclered  preliminary  until  they  are  formally  approved  and  distributed. 
^Combat  Systems  Test  &  Evaluation;  formerly  System  Test  &  Integration  (ST&I). 
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The  PDR  presentation  is  prepared  and  reviewed  by  the  Elements.  The  technical 
results  of  their  reviews  are  presented  to  Baseline  Management.  Baseline  Management 
then  conducts  a  review  of  the  Element  PDR  presentations  and  adds  the  programmatic 
scope,  schedule,  and  resource  requirements  and  approves  the  presentation. 

The  formal  PDR  is  chaired  by  PMS400B.  Acceptance  of  the  PDR  results  by  PMS400B 
and  a  formal  letter  authorizing  NSWCDD  to  proceed  to  the  High-Level  Design  Phase 
represent  completion  of  the  Element  Definition  Phase. 

PPS  and  PIDS  SCs  and  ICRs  are  updated  in  accordance  with  PDR  direction.  Baseline 
Management  updates  the  baseline  management  plan,  and  the  Elements  update  the 
functional  development  folders.  Documentation  Management  prepares  SCNs  or  new 
specifications  for  PPSs,  PIDS,  and  IDSs;  obtains  required  approvals;  and  arranges  for 
distribution  of  SCNs  and  new  specifications. 

There  are  seven  processes  in  the  Element  Definition  Phase: 

Conduct  Element  Analysis  and  Define  PPS  SCs  and  ICRs  (1.3.1) 

Prepare  and  Review  Preliminary  ICRs  (1 .3.2) 

Prepare  and  Review  Preliminary  PPS  SCs  (1.3.3) 

Update  Element  Development  Plans  and  Support  Program  Requirements 
(1.3.4) 

Develop  and  Review  PDR  Data  Package  (1 .3.5) 

Prepare  PDR  Presentation  and  Conduct  PDR  (1.3.6) 

Approve  and  Distribute  SCNs  and  New  Specifications  (1.3.7) 

Diagram  1.3  is  a  depiction  of  the  Element  Definition  Phase,  including  its  seven 
processes. 


18  November  1993 
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Activities,  Products,  and  Controi  Event 

Each  of  these  processes  consists  of  a  number  of  activities.  Table  1-3  is  a  matrix  of 
the  processes  and  their  constituent  activities. 

The  key  products  of  this  phase,  as  shown  in  the  process  model  in  Part  I,  are 

PIDS  SCs 

Preliminary  ICRs 

Preliminary  PPS  SCs 

Updated  Element  Development  Plan 

Simulator  Requirements 

PDR  Presentation 


Other  products  expected  to  result  from  conduct  of  the  activities  are  listed  below:^ 

Schedules 
Resource  Allocation 
Patch  Conversion  Plan 
Element  Performance  Disclosure 
Development  Tools  Definition 
Analysis  Tools 
Element  Support  Tools 
CASE  Tools 

Element  Test  Concept  Definition 
Identified  List  of  ACTS  and  CAST  Lessons 
Allocated  CPCR  List 

Man/Machine  Interface  Requirements  Definition 
Data  Analysis  Requirements  Definition 
User  Documentation  Plan 
Crew  Training  Impact  Report 
Baseline  Development  Folders 

The  single  control  event  for  this  phase  is  the  Preliminary  Design  Review,  whose 
purposes  are  to  review  validity  and  completeness  of  the  allocated  requirements  as  defined 
in  the  PIDSs,  PPSs,  and  IDSs;  apprise  PMS400  of  progress  and  plans;  and  obtain 
PMS400  authorization  to  proceed. 


Mn  the  event  of  a  discrepancy  between  this  list  and  the  details  shown  in  the  process  flows  and  activities  that  follow,  the  activities 
and  flows  should  be  followed. 
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TABLE  1-3.  MATRIX  OF  PROCESSES  IN  THE  ELEMENT  DEFINITION  PHASE 
AND  THEIR  CONSTITUENT  ACTIVITIES 


PROCESS 

ACTIVITY 

NUMBER 

TITLE 

DATE 

Conduct  Element  Analysis 

1.3.1.1 

Define  Required  PPS  SCs/ICRs 

29  Jul  94 

and  Define  PPS  SCs  and 

1.3.1. 2 

Perform  Requirements  Analysis 

29  Jul  94 

ICRs 

1.3.1.3 

Assess  Design  Impact 

1  Apr  96 

Prepare  and  Review 

1.3.2.1 

Prepare  Preliminary  ICRs 

18  Nov  93 

Preliminary  ICRs 

1. 3.2.2 

Conduct  Side  A  ECCB  Review  and  Approval  of 

Preliminary  ICRs 

18  Nov  93 

1. 3.2.3 

Conduct  Side  B  ECCB  Review  and  Approval  of 

Preliminary  ICRs 

18  Nov  93 

1. 3.2.4 

Conduct  NSWCDD  MK7  ICWG  Evaluation  of 

Preliminary  ICRs 

18  Nov  93 

1. 3.2.5 

Conduct  AWS  CRB  Preliminary  ICR  Processing  Present 

18  Nov  93 

1. 3.2.6 

Non  MK7  Preliminary  ICRs  for  Non  MKT  ICWG  Review 

and  Approval 

18  Nov  93 

Prepare  and  Review 

1.3.3.1 

Prepare  Preliminary  PPS  SCs 

29  Jul  94 

Preliminary  PPS  SCs 

1.3.3.1A 

Inspect  Preliminary  PPS  SCs 

29  Jul  94 

1. 3.3.2 

Conduct  ECCB  Review  and  Approval  of  Preliminary 

PPS  SCs 

18  Nov  93 

1. 3.3.3 

Conduct  AWS  CRB  Preliminary  PPS  SC  Processing 

18  Nov  93 

Update  Element  Development 

1.3.4.1 

Update  Element  Development  Plans 

18  Nov  93 

Plans  and  Support  Program 

1. 3.4.1  A 

Review  Element  Development  Plans 

27  Mar  95 

Requirements 

1. 3.4.2 

Update  Simulator  Requirements 

18  Nov  93 

1. 3.4.3 

Develop  Element  Test  Concept 

18  Nov  93 

1. 3.4.4 

Initiate  System  Test  Planning 

18  Nov  93 

1. 3.4.5 

Update  Baseline  Contents 

18  Nov  93 

Develop  and  Review  PDR 

Data  Package 

1. 3.5.1 

Prepare  PDR  Data  Package 

18  Nov  93 

1. 3.5.2 

Distribute  PDR  Data  Package  for 

Review 

18  Nov  93 

1.3.5.3 

Conduct  PDR  Data  Package  Review 

18  Nov  93 

1. 3.5.4 

Support  ERT  Review  of  PDR  Data  Package 

Comments 

18  Nov  93 

1. 3.5.5 

Support  SRT  Review  of  ERT  Comments  on  PDR  Data 

Package 

29  Jul  94 

Prepare  PDR  Presentation 

and  Conduct  PDR 

1. 3.6,1 

Prepare  Element  Portion  of  PDR  Presentation 

18  Nov  93 

1. 3.6.2 

Prepare  System  Engineering  Portion  of  PDR 

Presentation 

18  Nov  93 

1. 3.6.3 

Prepare  Baseline  Management  Portion  of  PDR 

Presentation 

18  Nov  93 

1. 3.6.4 

Conduct  Management  Review  of  PDR 

Presentation 

18  Nov  93 

1. 3.6.5 

Conduct  PDR 

18  Nov  93 

1. 3.6.6 

Update  PDR  Data  Package  Per  PMS400B 

Direction 

18  Nov  93 

Approve  and  Distribute  SCNs 

and  New  Specifications 

1. 3.7.1 

Process  and  Distribute  IDS  SCNs  and  New  IDSs 

18  Nov  93 

1, 3.7.2 

Obtain  Element  Approval  of  IDS  SCNs 

18  Nov  93 

1. 3.7.3 

Obtain  System  Engineering  Approval  of  IDS 

SCNs 

18  Nov  93 

1. 3.7.4 

Prepare  PPS  SCNs 

18  Nov  93 

1. 3.7.5 

Obtain  Approval  of  PPS  SCNs 

18  Nov  93 

1. 3.7.6 

Distribute  PPS  and  MK7  IDS  SCNs 

18  Nov  93 
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The  Conduct  Element  Analysis  and  Define  PPS  SCs  and  ICRs  Process  is 
comprised  of  three  activities  as  described  below.  Diagram  1.3.1  (Page  11-3-9)  is  a 
data  flow  diagram  of  the  process  and  its  constituent  activities. 

Activity:  ED-1.3.1.1 

DEFINE  REQUIRED  PPS  SCs  and  ICRs 

The  Element  leader  and  engineers  consider  the  AWS  and  ACS  SCs,  the  preliminary 
ICRs  and  IDSs  developed  in  the  System  Definition  Phase,  the  PIDS  SCs,  fleet  requests, 
lessons  learned,  known  design  shortcomings,  non-Mk  7  modifications,  and  the  baseline 
management  plan;  they  begin  to  specify  the  functional  design  and  compile  a  definition  of 
the  required  PPS  SCs  and  ICRs.  Finally,  the  engineers  make  a  determination  about  the 
patches  to  be  converted  to  source  code  and  allocate  them  to  the  builds.  They  document 
these  components  in  the  Element  development  plans.  An  example  of  the  data  considered 
for  establishing  the  baseline  definition  is  the  Government  Electronic  Systems-approved 
forward-fit  PPS  SCs  and  the  PMS400B-approved  ICRs.  Element  leaders  then  update  the 
baseline  definition  list  that  contains  the  SCs,  ICRs,  and  CPCRs  planned  for  incorporation 
and  the  Element  development  schedule.  They  coordinate  the  schedule  with  Baseline 
Management. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 

APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Elements 

Baseline  Management 
AWS  CRB  CM 
System  Engineering 
Fleet  Support 

None 

Element  Development  Plan  Standard 


Activity:  ED-1.3.1.2 

PERFORM  REQUIREMENTS  ANALYSIS 

Element  engineers  perform  the  required  analysis  to  document  the  requirements  in 
preliminary  SCs  at  the  PPS  level  and  identify  the  ICRs  that  are  required  at  the  IDS  level. 
System  changes  that  affect  multiple  Elements  are  specified  in  multi-element  working 
groups  initiated  and  coordinated  by  System  Engineering.  If  changes  are  required  to  the 
PIDS  SCs  due  to  the  preliminary  PPS  SCs  and  ICRs,  the  changes  are  made  and  the 
previous  change  control  cycle  is  repeated.  The  analysis  includes  an  evaluation  of  the 
proposed  changes  and  identification  of  data  analysis  requirements. 
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For  new  requirements  that  cross  several  Elements  and  require  modeling  and  computer 
simulation,  System  Engineering  coordinates  the  analysis/modeling/simulation  efforts 
between  the  impacted  elements. 

The  requirements  analysis  data  includes  evidence  that  the  problem  impacts  are  well 
understood.  Typical  analysis  products  may  include: 

(1 )  Models  of  algorithms 

(2)  Models  of  data  or  user  interface  design 

(3)  Control  flow  model  of  change 

(4)  Evaluation  of  model  performance 

(5)  Preliminary  impact  assessment  -  schedule,  cost,  time,  core,  etc. 

(6)  An  understanding  of  the  domain  of  change  (The  parts  of  the  system  that  change 
should  be  documented  within  a  boundary  of  system  components  that  do  not  change. 
This  should  adequately  address  logical  structure,  data  flow,  and  control  flow  at  the 
PPS  level.) 

(7)  Presentation  of  results  documented  in  reports,  graphs,  white  papers,  etc. 

These  inputs  are  compiled  in  the  Element  functional  development  folders.  The  Element 
leader  uses  the  results  of  the  requirements  analysis  to  refine  the  preliminary  SC  list  for 
input  to  Baseline  Management. 

PERFORMER: 

SUPPORTING  ORGANIZATION: 


APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Elements 

Baseline  Management 
System  Engineering 
AEGIS  Ships 

None 

None 
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Activity:  ED-1.3.1.3 
ASSESS  DESIGN  IMPACT 

Element  engineers  review  the  planned  requirements  that  pertain  to  their  element, 
including  interface  changes.  Changes  that  impact  the  architecture  of  the  computer 
programs  or  the  computer  program  environment  are  determined,  documented,  and  filed 
in  the  baseline  development  folder  for  subsequent  use  in  developing  or  updating  the 
element  development  plan. 

The  Elements  develop  and  document  design  goals  that  form  the  basic  guidance  for 
computer  program  designers  to  make  appropriate  choices  in  deciding  among  alternatives 
as  they  implement  allocated  requirements.  Such  goals  should  include  one  or  more  of  the 
following  (including  specified  priorities  when  multiple  goals  are  specified): 

-  Resource  conservation  (minimizing  impact  on  core,  time  utilization,  or  interface  impact) 

-  Efficiency  (i.e.,  the  resources  required  by  a  program;  each  of  the  following  resources 
must  be  considered:  cpu,  memory,  online  storage,  I/O  and  human  development  effort) 

-  Maintainability  (i.e.,  the  effort  required  to  locate  and  correct  an  error) 

-  Flexibility  (i.e.,  the  effort  required  to  modify  an  operational  program) 

-  Reusability  (i.e.,  the  extent  to  which  parts  of  a  program  can  be  reused  in  other 
applications) 


PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  Program  Design  Document  Standard 
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5.  BUILD  IMPLEMENTATION  PHASE 


The  Build  Implementation  Phase  consists  of  a  sequence  of  one  or  more  builds 
during  which  each  computer  program  unit  identified  during  the  High-Level  Design  Phase 
is  developed  and  checked  out.  Independent  of  these  builds,  support  tools  and  the  system 
test  plan  are  created  or  updated,  as  appropriate. 

Existing  plans  are  reviewed  to  determine  updates  that  must  be  made  to  reflect 
changes.  The  plans  are  further  refined  as  required  to  implement  the  Build  Implementation 
Phase  activities.  This  includes  scheduling  of  the  detailed  design,  code,  and  unit  test  of 
each  unit  that  is  to  be  a  part  of  the  build.  Because  individual  units  are  of  varying  size  and 
complexity,  different  units  may  be  at  different  steps  in  the  build  process  at  the  same  time. 
For  example,  while  a  relatively  small  unit  may  have  progressed  to  the  unit  test  step,  a 
much  larger  unit  may  still  be  in  the  detailed  design  step. 

As  units  complete  unit  testing,  they  are  executed  in  a  load  file  with  previously 
completed  units  and  the  rest  of  the  Element  and  other  Elements  or  simulators  to  ensure 
that  no  recently  integrated  unit  has  an  adverse  effect  on  previously  tested  code.  This 
results  in  a  gradual  integration  of  all  units  planned  for  development. 

At  the  conclusion  of  each  build,  a  Build  Implementation  Review  (BIR)  is  conducted 
to  discuss  the  results  of  all  build  activities.  Special  emphasis  is  placed  on  any  facts  or 
plans  disclosed  at  prior  reviews  which  might  be  invalidated  by  the  recently  completed  build. 
The  BIR  for  the  final  build  summarizes  the  disclosures  of  the  previous  BIRs  and  serves  as 
the  control  event  that  signals  the  completion  of  the  Build  Implementation  Phase.  The  BIR 
is  documented,  action  items  are  assigned,  and  the  action  items  are  tracked  to  closure.  The 
final  BIR  is  the  control  event  that  ensures  completeness  of  all  code  and  unit  testing 
activities  for  all  builds  and  serves  as  a  status  report  to  Baseline  Management.  There  are 
nine  processes  in  the  Build  Implementation  Phase: 

1 .  Update  Development  Plan 

2.  Plan  Unit  Test  Activities 

3.  Develop  Unit  Detailed  Design 

4.  Develop  Unit  Test  Procedures 

5.  Produce  Code/Perform  Unit  Testing 

6.  Perform  Build  Integration  and  Testing 

7.  Conduct  Build  Implementation  Review  (BIR) 

8.  Perform  Supporting  Activities 

9.  Produce  System-Level  Test  Plan 
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For  developments  involving  multiple  builds,  processes  1  through  7,  referred  to  collectively 
as  the  build  process,”  are  repeated  for  each  build  identified  in  the  element  development 
plan. 


Diagram  1.5  (Page  II-5-5)  is  a  depiction  of  the  Build  Impiementation  Phase, 
including  its  nine  processes. 

Activities,  Products,  and  Control  Event 

Most  of  the  nine  processes  consist  of  a  number  of  activities.  Table  II-5-1  is  a 
matrix  of  the  processes  and  their  constituent  activities. 

The  key  products  of  this  phase  are 

Program  Design  Document 

Database  Design  Documents 

Element  QA  Reports 

Unit  Test  Procedures 

System-Level  Test  Plan 

Element  Test  Procedures 

Source  Code 

Unit  Test  Reports 

Executable  Computer  Programs 

Build  Implementation  Review  (BIR)  Presentation 

Element  Test  Disclosure  Review  Presentation 

The  control  events  for  this  phase  are  the  BIRs,  held  at  the  completion  of  each 
build.  The  purpose  of  a  BIR  is  to  discuss  the  results  of  all  build  activities.  Process 
1 .5.7  is  representative  of  BIRs  iterative  throughout  this  phase.  The  final  BIR,  at  the 
conclusion  of  the  final  build,  marks  the  end  of  the  phase. 
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TABLE  11-5.  MATRIX  OF  PROCESSES  IN  THE  BUILD  IMPLEMENTATION  PHASE 

AND  THEIR  CONSTITUENT  ACTIVITIES 


PROCESS 


ACTIVITY 


PROCESS 


NUMBER  TITLE 


DATE 


Update  Development  Plan  1 .5.1 .1  Review  Commitments  1  Apr  96 

1.5.1. 2  Plan  Current  Build  1  Apr  96 

Plan  Unit  Test  Activities  1 .5.2.1  Define  Approach  for  Verifying  Each 

Impacted  Unit  1  Apr  96 

1 .5.2.2  Update  Element  Development  Plan  1  Apr  96 

Develop  Unit  Detailed  Design  1 .5.3.1  Perform  Predesign  Analysis  1  Apr  96 

(For  Each  Unit)  1  5.3.2  Develop  Unit  Design  1  Apr  96 

1 .5.3.3  Update  and  Verify  Interface  Changes  1  Apr  96 

1 .5.3.4  Update  Design  Document  1  Apr  96 

1 .5.3.5  Review  Detailed  Design  1  Apr  96 

Develop  Unit  Test  Procedures  1 .5.4. 1  Analyze  Unit  Test  Factors  1  Apr  96 

(For  Each  Unit)  1  5.4.2  Develop  Unit  Test  Procedures  1  Apr  96 

1 .5.4.3  Review  Unit  Test  Procedures  1  Apr  96 

Produce  Code/Perform  1. 5.5.1  Implement  Changes  to  Code  1  Apr  96 

Unit  Testing  1  -5.5.2  Perform  Code  Inspection  1  Apr  96 

1 .5.5.3  Assemble  Test  Unit  1  Apr  96 

1 .5.5.4  Perform  Unit  Testing  1  Apr  96 

1 .5.5.5  Analyze  Test  Results  1  Apr  96 

Perform  Build  Integration  and  1. 5.6.1  Assemble  Load  File  1  Apr  96 

Testing  1 .5.6.2  Perform  Build  Integration  and  Test  1  Apr  96 

1 .5.6.3  Analyze  Test  Results  1  Apr  96 

1 .5.6.4  Prepare  Element  QA  Report  1  Apr  96 

Conduct  Build  Implementation  1 .5.7.1  Prepare  Documentation  for  BIR  1  Apr  96 

Review  (BIR)  1  5.7.2  Conduct  BIR  Meeting  1  Apr  96 

1 .5.7.3  Perform  BIR  Corrective  Actions  1  Apr  96 

Perform  Supporting  Activities  1 .5.8.1  Upgrade  Analysis  Tools  and 

Documentation  1  Apr  96 

1 .5.8.2  Prepare  Element  Test  Documentation  1  Apr  96 

1 .5.8.3  Inspect  Element  Test  Procedures  1  Apr  96 

1 .5.8.4  Build  System  QA/Element-Controlled  Load  Files  1  Apr  96 

1 .5.8.5  Update  Element  Test  Disk  Packs  1  Apr  96 

1 .5.8.6  Develop  Special  Element  Engineering 

Tests  '•  Apr  96 


Produce  System-Level  Test 
Plan 


1 .5.9.1  Write  System-Level  Test  Plan 


1  Apr  96 
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1.5.1  UPDATE  DEVELOPMENT  PLAN  PROCESS 

The  Update  Development  Plan  Process  is  comprised  of  two  activities  as 
described  below.  Diagram  1.5.1  (Page  il-5-9)  is  a  data  flow  diagram  of  the  process 
and  its  two  constituent  activities. 


Activity:  BI-1 .5.1.1 
REVIEW  COMMITMENTS 


The  Elements  review  the  baseline  management  plan  and  the  element  development 
plan  along  with  any  emergent  non-SC  CPCRs  that  are  to  be  included  in  the  current  build. 
They  review  the  component  description,  design  approach,  element  computer  program 
breakdown,  and  module  design  descriptions  of  the  program  design  document  to  identify 
the  modules  and  common  data  that  will  be  impacted.  Based  on  this  review,  they  assess 
the  allocation  of  CPCRs  to  builds  and  determine  the  final  CPCR  to  build  allocation.  The 
element  development  plan  is  updated  to  reflect  any  changes.  They  process  CPCRs  that 
have  high-level  design  impact  in  accordance  with  the  defined  high-level  design  process, 
prior  to  reaching  build  integration. 

The  Elements  ensure  that  Baseline  Management  is  aware  of  any  changes  which 
impact  inter-Element  interfaces.  They  coordinate  those  changes  with  both  Baseline 
Management  and  the  affected  elements  in  terms  of  both  functionality  and  schedule. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Elements 

Baseline  Management 
None 

Baseline  Management  Plan  Standard 
Element  Development  Plan  Standard 
AWS  CRB  Procedures 
(AEGIS  Document-94/5) 


Activity:  BI-1 .5.1.2 
PLAN  CURRENT  BUILD 

The  Elements  first  identify  and  define  all  interim  and  final  products  required  for  the 
build.  They  then  identify  each  task  required  to  prepare  each  of  those  products  and 
estimate  the  resources  required  for  their  performance.  Required  resources  are  compared 
with  those  available  and  the  sequence  of  tasks  is  altered,  as  necessary,  to  balance 
available  and  required  resources. 
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The  Element  then  updates  the  risk  management  section  of  the  element 
development  plan,  including  the  following,  as  appropriate: 

Risk  factors 

Risk  probabilities  and  effects  on  the  project 

Strategies  to  mitigate  identified  risks  (e.g.,  action  plans,  contingency  plans) 
Methods  to  monitor  the  risk  factors 

A  contingency  plan  (when  a  quantitative  risk  indicator  crosses  a 
predetermined  threshold). 

Risk  management  plan  (how  to  manage  the  crisis  through  reallocation  of 
resources  and  reevaluation),  and 
Description  of  how  to  recover  from  the  crisis. 

Considering  the  risk  mitigation  and  reduction  activities,  the  Elements  may  reallocate 
the  resources  and  modify,  add,  or  resequence  steps.  When  all  risk-motivated  issues  are 
worked  into  the  plan,  the  Elements  assign  specific  responsibilities  for  each  identified  task. 
Finally,  they  update  the  element  development  plan  to  reflect  the  revised  build  plan  and 
schedule. 

PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  Element  Development  Plan  Standard 
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1 .5.2  PLAN  UNIT  TEST  ACTIVITIES  PROCESS 

The  Plan  Unit  Test  Activities  Process  is  comprised  of  two  activities  as 
described  below.  Diagram  1.5.2  (Page  II-5-13)  is  a  data  flow  diagram  of  the  process 
and  its  two  constituent  activities. 


Activity:  BI-1 .5.2.1 

DEFINE  APPROACH  FOR  VERIFYING  EACH  IMPACTED  UNIT 

The  Elements  review  each  unit  impacted  by  changes  in  the  build  in  terms  of  both 
requirements  and  design  to  determine  the  best  approach  for  verifying  the  unit  upon 
modification.  They  identify  the  required  test  environment,  including  tactical  environment 
and  load  file,  where  appropriate,  and  identify  simulators  required  to  support  the 
environment.  They  also  specify  other  Elements,  computer  programs,  units,  or  drivers 
required  to  support  the  environment.  The  Elements  determine  any  dependent,  concurrent 
changes  and  identify  the  data  that  must  be  analyzed.  Next,  they  identify  all  required 
physical  resources.  And  finally,  the  Elements  verify  the  availability  of  required  resources. 


PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 


Activity:  BI-1 .5.2.2 

UPDATE  ELEMENT  DEVELOPMENT  PLAN 

The  Elements  update  the  element  development  plan  schedule  to  reflect  the  defined 
verification  approach.  They  make  any  required  adjustments  to  accommodate  resource 
availability,  and  negotiate  concurrence  among  all  participants.  The  Element  group  leader 
verifies  that  the  plan  is  viable  and  adequately  addresses  risks. 

PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  Element  Development  Plan  Standard 
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1.5.3  DEVELOP  UNIT  DETAILED  DESIGN  (FOR  EACH  UNIT)  PROCESS 

The  Develop  Unit  Detailed  Design  (For  Each  Unit)  Process  is  comprised  of  five 
activities  as  described  below.  Diagram  1.5.3  (Page  11-5-19)  is  a  data  flow  diagram  of 
the  process  and  its  five  constituent  activities. 


Activity:  BI-1 .5.3.1 

PERFORM  PREDESIGN  ANALYSIS 


The  Elements  identify  each  impacted  unit  in  the  element  development  plan.  For 
each  unit,  they  review  relevant  SCs  and  the  PPS  to  ensure  a  thorough  understanding  of 
each  new  or  changed  requirement  (or  existing  requirement  in  the  case  of  non-SC  CPCRs). 
The  Elements  also  review  existing  design  documentation  (when  practical)  and  existing 
code  to  ensure  an  understanding  of  the  detailed  design  of  both  the  impacted  unit  and 
those  units  with  which  it  directly  interfaces. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Elements 

None 

None 

Element  Development  Plan  Standard 
Program  Design  Document  Standard 


Activity:  Bi-1 .5.3.2 
DEVELOP  UNIT  DESIGN 

After  all  requirements  and  the  surrounding  detailed  design  are  understood  by  the 
Elements,  they  develop  and  document  algorithms  to  satisfy  the  new  or  changed 
requirements  (normally  via  flow  charts  or  Program  Design  Language  (PDL)).  During 
algorithm  development,  the  Elements  identify  new  and  existing  data  structures  required  to 
support  the  algorithms.  As  the  trial  unit  design  evolves,  the  Elements  review  it  to 
determine  if  additional  legality  checks,  error  processing,  or  exception  handling  is  required. 
They  analyze  the  possible  content  of  all  data  items  used  by  the  unit  to  determine  if  special 
initialization  processing  is  needed.  As  the  trial  unit  design  is  finalized,  the  Elements  define 
new  or  modified  data  structures  to  ensure  required  accuracy.  After  the  design  has  been 
completed  and  reviewed  for  accuracy,  the  Elements  develop  or  update  core  and  timing 
estimates  for  the  unit. 
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PERFORMER: 

Elements 

SUPPORTING  ORGANIZATION: 

None 

APPROVAL  REQUIRED: 

None 

APPLICABLE  INSTRUCTION: 

None 

Activity:  BI-1 .5.3.3 

UPDATE  AND  VERIFY  INTERFACE  CHANGES 

The  Elements  contrast  the  trial  unit  design  with  all  sections  of  the  program  design 
document  to  ensure  that  unit  design  activities  do  not  violate  or  negate  any  facet  of  the 
high-level  design.  They  adjust  the  high-level  or  detailed  design,  as  appropriate.  The 
Elements  also  review  the  design  of  interfacing  units  for  efficiency  and  accuracy  in  view  of 
the  unit  being  modified.  If  the  unit  interfaces  with  another  Element,  the  Element  reviews 
the  design  of  both  units  comprising  the  interface  with  their  counterparts  in  the  other 
affected  Element.  They  consider  and  note  improvements  in  a  verified  unit  design. 

PERFORMER: 

Elements 

SUPPORTING  ORGANIZATION: 

None 

APPROVAL  REQUIRED: 

None 

APPLICABLE  INSTRUCTION: 

Program  Design  Document  Standard 

Activity:  BI-1 .5.3.4 

UPDATE  DESIGN  DOCUMENT 

The  Elements  update  the  shared  data  and  unit  (or  subprogram)  processing  sections 
of  the  program  design  document  to  reflect  all  changes  as  documented  in  the  verified  unit 
design.  Sections  of  the  program  design  document  produced  in  earlier  phases  are  reviewed 
for  consistency  with  the  updated  sections.  All  discrepancies  are  reconciled  and 
appropriate  changes  are  made. 

PERFORMER: 

Elements 

SUPPORTING  ORGANIZATION: 

None 

APPROVAL  REQUIRED: 

None 

APPLICABLE  INSTRUCTION: 

Program  Design  Document  Standard 
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The  detailed  design  of  each  unit  undergoing  change  is  reviewed  during  a  formal 
design  review.  This  activity  begins  by  identifying  the  areas  to  be  reviewed  and  often 
includes  interfacing  units  as  well  as  the  units  which  were  the  primary  focus  of  the  change. 

Elements  choose  review  participants  based  on  their  knowledge  of  the  affected  area 
and  their  ability  to  detect  errors  in  the  detailed  design.  In  units  with  complex  interfaces, 
some  participants  may  be  chosen  based  on  their  knowledge  of  the  interfacing  units  rather 
than  the  one  actually  being  reviewed.  The  Elements  collect  materials  to  be  reviewed  from 
information  contained  in  the  program  design  document,  CPCR  folders,  and  working  papers 
of  the  element  engineers  who  performed  the  actual  design.  They  conduct  each  review  in 
accordance  with  documented  element  procedures.  System  and  Element  QA  verify 
compliance  with  those  procedures,  and  document  the  results. 

The  Elements  correct  all  defects  identified  during  the  review,  and  update  all 
appropriate  documents  accordingly.  In  addition,  the  Elements  and  System  QA  update  the 
Element  and  system  metric  files  with  pertinent  data  about  the  review. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Elements 
System  QA 
None 

Element  Design  Review  Procedure 
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1.5.4  DEVELOP  UNIT  TEST  PROCEDURES  (FOR  EACH  UNIT)  PROCESS 

The  Develop  Unit  Test  Procedures  Process  is  comprised  of  three  activities  as 
described  beiow.  Diagram  1.5.4  (Page  11-5-25)  is  a  data  flow  diagram  of  the  process 
and  its  three  constituent  activities. 


Activity:  BI-1 .5.4.1 
ANALYZE  UNIT  TEST  FACTORS 

The  Elements  analyze  factors  affecting  unit  test  of  the  code  to  be  developed  from 
the  modified  design  to  determine  the  optimum  environment  (e.g.,  ACC,  Vax)  and  method 
fortesting  each  unit.  In  addition,  they  consider  and  identify  the  various  conditions  under 
which  the  unit  must  be  tested.  The  Elements  study  both  the  high-level  and  detailed  design 
of  the  affected  unit  to  determine  the  best  approach  for 

Executing  the  unit 

Providing  necessary  data  to  the  unit 
Observing  the  expected  outputs  from  the  unit 

The  Elements  also  explicitly  define  the  test  criteria,  consisting  of  specific  data  inputs  and 
the  expected  results,  methods  for  scheduling  the  unit,  and  the  method  for  recording  the 


output  values. 

PERFORMER;  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 


Activity:  Bi-1 .5.4.2 

DEVELOP  UNIT  TEST  PROCEDURES 

The  Elements  use  test  criteria  for  preparing  a  written  unit  test  procedure,  written  with 
sufficient  detail  to  be  repeatable  by  Element  personnel,  that  documents  each  of  the 
following: 

1 .  The  hardware,  firmware,  and  software  including  tactical  and  simulation  load 
files,  applicable  patch  files,  etc.,  to  be  used  during  the  testing  of  each  unit. 
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2.  The  steps  required  to  prepare  the  test  environment.  This  documents 
which  files  are  loaded  in  which  computers,  initialization  procedures, 
assignment  of  operators  to  consoles,  etc. 

3.  The  sequence  of  steps  (e.g.,  VAB  actions  or  console  commands),  to  be  used 
during  the  actual  test  and  the  expected  results. 

4.  The  steps  to  be  taken  to  collect  data  for  analysis  or  observations  to  be  made 
and  recorded  in  order  to  assess  the  outcome  of  the  test. 

5.  The  steps  to  be  performed  in  analyzing  output  data  or  observations, 
including  explicit  pass/fail  criteria  for  each  data/observation  set. 


PERFORMER; 

Elements 

SUPPORTING  ORGANIZATION: 

None 

APPROVAL  REQUIRED: 

None 

APPLICABLE  INSTRUCTION: 

None 

Activity:  BI-1 .5.4.3 

REVIEW  UNIT  TEST  PROCEDURES 

The  Elements  review  unit  test  procedures.  One  or  more  procedures  are  chosen  for 
each  individual  review  based  on  their  size,  complexity,  and  the  expected  length  of  the  actual 
review.  This  process  is  repeated  until  all  procedures  have  been  reviewed. 

Review  participants  are  chosen  based  on  their  knowledge  of  the  areas  to  be  tested 
and  their  ability  to  detect  errors  in  the  procedure.  In  units  with  complex  interfaces,  some 
participants  may  be  chosen  based  on  their  knowledge  of  the  interfacing  units  rather  than 
the  one  actually  being  inspected.  In  addition  to  the  test  procedure  itself,  other  materials 
useful  to  the  reviewers  are  collected  from  information  contained  in  the  program  design 
document,  CPCR  folders,  and  working  papers  of  the  Element  engineers  who  designed  the 
unit  or  wrote  the  test  procedure.  Each  review  is  conducted  in  accordance  with  standard 
procedures.  Element  and  System  QA  verify  compliance  with  those  procedures  and 
document  the  results. 

All  defects  identified  during  the  review  are  corrected  and  all  appropriate  documents 
are  updated  accordingly.  In  addition.  Element  and  System  metric  files  are  updated  with 
pertinent  data  about  the  review. 
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PERFORMER: 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Elements 
System  QA 
None 
None 
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1.5.5  PRODUCE  CODE/PERFORM  UNIT  TESTING  PROCESS 

The  Produce  Code/Perform  Unit  Testing  Process  is  comprised  of  four 
activities  as  described  below.  Diagram  1.5.5  (Page  11-5-31)  is  a  data  flow  diagram  of 
the  process  and  its  four  constituent  activities. 


Activity:  BI-1 .5.5.1 
IMPLEMENT  CHANGES  TO  CODE 

Element  engineers  are  assigned  units  for  coding  based  on  the  schedule  in  the 
element  development  plan.  Element  engineers  must  become  familiar  with  the  detailed 
design,  the  code  surrounding  the  area  to  be  changed,  and  the  code  in  interfacing  units 
before  coding  actually  begins.  In  addition,  they  examine  all  data  to  be  used  by  the  new 
code. 


When  the  engineers  are  satisfied  with  their  understanding  of  the  indicated  areas, 
they  write  the  actual  code  in  accordance  with  AEGIS  coding  standards  and  upon 
completion,  desk-check  and  compile  the  code.  The  engineers  repeat  this  process  until 
all  compilation  errors  are  eliminated. 

PERFORMER;  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  Applicable  Coding  Standards 


Activity:  BI-1 .5.5.2 

PERFORM  CODE  INSPECTION 

During  a  formal  code  inspection,  the  Elements  review  the  code.  They  choose  one 
or  more  units  for  an  individual  inspection  based  on  their  size  and  complexity  and  the 
expected  length  of  the  actual  inspection. 

Elements  choose  inspection  participants  based  on  their  knowledge  of  the  code  to  be 
inspected  and  their  ability  to  detect  code  errors.  In  units  with  complex  interfaces,  some 
participants  may  be  chosen  based  on  their  knowledge  of  the  interfacing  units  rather  than  the 
one  actually  being  inspected.  In  addition  to  the  code  itself,  the  Elements  collect  other 
materials  useful  to  the  inspectors  from  information  contained  in  the  program  design 
document,  CPCR  folders,  or  working  papers  of  the  Element  engineers  who  developed  the 
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design  or  wrote  the  code.  Elements  conduct  each  inspection  in  accordance  with  standard 
procedures.  Element  and  System  QA  verify  compliance  with  those  procedures  and 
document  the  results. 

PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  Applicable  Computer  Program  Coding  Standards 

Inspection  Standard 


Activity:  BI-1 .5.5.3 
ASSEMBLE  TEST  UNIT 

Element  engineers  release  their  testable  unit  to  their  Element  QA  representative.  The 
Element  QA  representative  places  the  testable  unit  into  an  Element-controlled  area.  Then 
the  Element  QA  representative  ensures  that  the  testable  unit  complies  with  all  Element 
guidelines  and  QAIs.  If  necessary,  the  Element  QA  representative  compiles  the  appropriate 
files  and  creates  a  load  file. 

PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  Program  Maintenance  and  Software  Quality 

Assurance  in  the  VAX  Environment,  QAI  202 


Activity:  BM  .5.5.4 
PERFORM  UNIT  TESTING 

The  Elements  prepare  the  test  environment,  including  the  construction  of  any 
required  load  files,  and  set  it  up  in  accordance  with  the  documented  test  procedure.  They 
execute  each  step  in  the  test  sequence,  as  written.  The  Elements  also  collect  data  and 
record  observations,  as  specified  in  the  test  procedure.  Element  engineers  note 
discrepancies  in  the  test  procedure  and  reexecute  the  test  at  the  direction  of  the  unit  test 
personnel.  The  Elements  update  the  test  procedure  to  reflect  each  noted  change. 
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PERFORMER: 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Elements 

None 

None 

Element  Development  Plan  Standard 


Activity:  BI-1 .5.5.5 
ANALYZE  TEST  RESULTS 

The  Elements  compare  relevant  recorded  observations  and  collected  data  with  their 
expected  values  and  pass/fail  criteria  as  documented  in  the  unit  test  procedures.  They 
analyze  data  that  fails  to  meet  pass  criteria  to  determine  the  cause  and  the  appropriate 
correction.  The  Elements  then  document  results,  including  all  corrective  action,  in  the  unit 


test  report. 

PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 
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1.5.6  PERFORM  BUILD  INTEGRATION  AND  TESTING  PROCESS 

The  Perform  Build  Integration  and  Testing  Process  is  comprised  of  four 
activities  as  described  beiow.  Diagram  1.5.6  (Page  ii-6-37)  is  a  data  flow  diagram  of 
the  process  and  its  four  constituent  activities. 


Activity:  Bi-1 .5.6.1 
ASSEMBLE  LOAD  FILE 

The  Elements  select  a  set  of  compatible  units  for  the  initial  build  integration  load  file. 
Based  on  that  set  of  units,  they  compile  appropriate  files  and  create  a  load  file.  Element  QA 
scans  the  files  collecting  the  embedded  CPCR  numbers,  which  are  verified  against  the 
closure  memo  and  ACCESS  records.  The  Elements  test  this  load  as  described  in  the 
following  two  activities.  Upon  completion  of  activity  BI-1 .5.6.3,  the  Elements  add  additional 
units  to  the  next  load  file  and  perform  additional  testing.  They  repeat  this  process  until  all 
units  scheduled  for  the  current  build  are  included  and  demonstrated  to  be  working. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION; 


Elements 

None 

None 

CRB  Procedures 


Activity:  BI-1 .5.6.2 

PERFORM  BUILD  INTEGRATION  AND  TEST 

The  Elements  define  an  appropriate  test  environment  based  on  the  Element  and  the 
functional  capabilities  to  be  exercised,  as  defined  in  the  element  development  plan.  They 
identify  the  specific  hardware,  simulators,  and  particular  MEIT  load  files  for  other  AEGIS 
Elements  to  be  used  during  the  integration  effort. 

The  Elements  prepare  informal  test  procedures  with  pass/fail  criteria.  These 
procedures  focus  on  four  different  types  of  testing: 

1 .  Functional  tests  which  demonstrate  that  the  new  or  modified  units  satisfy  their 
functional  requirements.  These  tests  must  demonstrate  that  the  full  range  of 
inputs  produce  the  expected  outputs  within  the  allowable  fidelity  of  the  test 
environment. 
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2.  Regression  tests  to  ensure  that  the  new  or  modified  units  do  not  have  an 
adverse  effect  on  previously  tested  capabilities.  During  build  integration, 
regression  testing  focuses  on  existing  capabilities  supported  by  the  modified 
units  or  by  units  that  directly  interface  with  new  or  modified  units. 

3.  Performance  tests  that  focus  on  critical  or  planned  timing  characteristics  of  the 
system.  This  testing  can  occur  in  either  of  two  different  situations.  One 
ensures  that  critical  performance  characteristics  have  not  been  adversely 
affected  (e.g.,  minimum  response  time  can  still  be  met).  The  other  focuses  on 
overall  system  throughput  (e.g.,  Is  the  new  build  consuming  so  much 
additional  CPU  time  that  subsequent  builds  will  not  be  able  to  work?). 

4.  Operational  tests  that  ensure  that  all  system  capabilities  function  collectively. 

In  many  cases,  the  Elements  correct  problems  as  they  are  discovered  during 
integration  testing.  In  other  cases,  they  may  choose  to  collect  data  and  analyze  it  at  a  later 
time. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Elements 

None 

None 

Element  Development  Plan  Standard 


Activity:  BI-1 .5.6.3 
ANALYZE  TEST  RESULTS 

The  Elements  collect  all  recorded  observations  and  compare  the  data  with  their 
expected  values  and  pass/fail  criteria  as  documented  in  the  informal  procedures 
documented  in  the  previous  activity.  They  analyze  data  that  fails  to  meet  pass  criteria  to 
determine  the  cause  and  make  corrections.  In  addition,  the  Elements  assess  the  overall 
effectiveness  of  the  integration  effort  for  the  current  build.  If  required,  the  Elements  may 


prescribe  additional  testing. 

PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 
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Activity:  BI-1 .5.6.4 

PREPARE  ELEMENT  QA  REPORT 


Build  Implementation 


Element  QA  reviews  the  overall  conduct  of  the  build  by  comparing  results  with  the 
element  development  plan  and  any  applicable  element  standards  and  procedures.  They 
document  specific  deviations  in  the  Element  QA  report.  The  Elements  collect  and 
document  the  required  metrics. 

PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  Element  QA  Report  Standard  (TBD) 
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1.5.7  CONDUCT  BUILD  IMPLEMENTATION  REVIEW  (BIR)  PROCESS 

The  Conduct  Build  Implementation  Review  (BIR)  Process  is  comprised  of  three 
activities  as  described  below.  Diagram  1.5.7  (Page  11-5-41)  is  a  data  flow  diagram  of 
the  process  and  its  three  constituent  activities. 

Activity:  BI-1 .5.7.1 

PREPARE  DOCUMENTATION  FOR  BIR 


Upon  completion  of  all  unit  developments  and  the  integration  of  all  units  in  the  build, 
the  Elements  prepare  for  the  BIR.  Prior  to  the  BIR,  the  Elements  update  the  CPCR  folders 
and  baseline  development  folders.  The  Elements  assemble  information  to  define  and 
describe  the  status  of  unit  development  and  unit  integration  activities.  The  Elements  then 
perform  impact  assessments  of  the  present  build  upon  previous  and  subsequent  builds. 
They  assess  and  document  any  impact  on  high-level  design  or  requirements.  And  they 
assemble  the  information  into  a  presentation  for  review  by  the  branch  head. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Elements 

None 

None 

Standard  for  Review  Process 


Activity:  BI-1 .5.7.2 

CONDUCT  BIR  MEETING 

At  the  end  of  each  build  the  Element  conducts  an  internal.  Element-level  BIR  for  the 
Element  group  leader  and  selected  Element  personnel.  The  reviewers  verify  the  adequacy 
of  build  implementation,  ensuring  that  activities  include  adequate  inter-unit  and  inter-build 
coordination  as  well  as  quality  verification  activities.  They  determine  the  status  of  unit 
documentation  and  identify  corrective  actions,  which  are  assigned  to  individuals  and  tracked 
to  closure. 

For  the  final  build  and  for  any  build  which  resulted  in  unexpected  high-level  design 
changes  or  significant  changes  to  other  Elements,  additional  procedures  are  required.  First, 
the  list  of  reviewers  must  include  Baseline  Management  and  all  affected  branch  heads. 
Second,  the  review  must  be  expanded  to  include  each  of  the  following: 

1 .  All  areas  of  high-level  design  which  were  impacted  as  well  as  the  detailed 
design  which  supports  those  areas. 
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2.  All  areas  that  caused  changes  to  other  Elements  with  emphasis  on  the  inter- 
Element  coordination  and  verification  activities. 

Responsibilities; 

Preparer-Element  Build  Personnel 

Reviewer  (Normal)-Element  Group  Leader;  Element  Branch  Head 

Reviewer  (Final/Expanded)-Element  Group  Leader,  all  Affected  Branch 
Heads,  Baseline  Management 

Coordinator-Element  Build  Leader 

Authorizing  Agent-Element  Branch  Head 

PERFORMER:  Elements 


SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED; 
APPLICABLE  INSTRUCTION: 


Baseline  Management 
None 

Standard  for  Review  Process 


Activity:  BI-1 .5.7.3 

PERFORM  BIR  CORRECTIVE  ACTIONS 

The  Elements  perform  the  assigned  corrective  actions  from  the  Element-level  BIR. 
The  corrective  actions  may  involve  making  design  changes,  performing  additional 
verification  activities,  preparing  or  updating  documentation,  or  providing  additional 
information  regarding  status  or  design  impact.  Upon  completion  of  all  action  items  and  upon 
obtaining  authorization  to  proceed  to  the  next  phase,  the  Elements  request  that  MEIT 
update  the  MEIT  jump  load. 

PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  MEIT  (Pack  Management) 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 
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1.5.8  PERFORM  SUPPORTING  ACTIVITIES  PROCESS 

The  Perform  Supporting  Activities  Process  is  comprised  of  six  activities  as 
described  below.  Diagram  1.5.8  (Page  11-5-47)  is  a  data  flow  diagram  of  the  process 
and  its  six  constituent  activities. 


Activity:  BI-1 .5.8.1 

UPGRADE  ANALYSIS  TOOLS  AND  DOCUMENTATION 

For  each  build  affecting  the  data  dictionary,  the  Elements  transfer  the  data  dictionary 
to  the  analysis  facility.  With  support  from  SCP,  they  use  the  extraction  point  attribute 
collector  (EPAC)  text  file  generated  by  SYSBLD  and  the  dump  of  the  data  recording  item 
selection  table  (DRIST)  to  generate  data  dictionary  files  each  time  a  new  load  is  built.  They 
generate  the  files  and  install  them  on  the  AEGIS  data  reduction  (ADAR)  system  where  the 
files  can  be  accessed  by  the  Elements  for  reducing  tactical  data. 

For  each  build,  the  Elements  update  the  analysis  computer  programs.  This  involves 
updating  analysis  and  special-purpose  programs  that  are  affected  by  changes  in  the  data 
dictionary.  At  the  end  of  the  last  build,  the  Elements  update  the  extraction  and  reduction 
inputs  as  follows: 

Determine  data  recording  extraction  points  (EP)  sets 

Generate  data  reduction  templates  and/or  update,  test,  and  verify 

Prepare  message  direction  inputs  for  EPs  for  intercomputer  messages 

Determine  the  periodicity  of  EPs  where  required 

Finally,  at  the  end  of  the  last  build,  the  Elements,  supported  by  Baseline  Control, 
update  the  computer  room  error  code  guide  and  data  recording/data  extraction  (DX/DR) 


guidelines  inputs. 

PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  SCP 

Baseline  Control 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 


11-5-43 


1  April  1996 


Build  Implementation  NSWCDD/MP-93/85 

Activity:  BM  .5.8.2 

PREPARE  ELEMENT  TEST  DOCUMENTATION 

The  Elements  complete  all  documentation  and  preparations  necessary  for  conducting 
the  Element  Test  Disclosure  Review  (ETDR).  As  required,  the  Elements  review  the  Element 
test  requirements  (documented  in  section  4  of  the  PPS),  and  review  and  update  the  Element 
test  plans  that  were  developed  during  the  high-level  design  phase.  The  Elements  develop 
required  test  cases  in  accordance  with  the  updated  Element  test  plan.  They  prepare  test 
procedures  for  each  test  identified  in  the  Element  test  plan.  The  Elements  then  review  the 
Element  test  procedures.  The  Elements  reconcile  procedure  errors,  and  the  manager 
determines  if  there  is  a  need  for  a  follow-on  review  before  they  are  inspected.  Upon 
resolution  of  all  deficiencies,  the  Elements  place  a  copy  of  the  Element  test  procedures  in 
the  baseline  development  folder.  The  Elements  prepare  an  ETDR  presentation  package 
that  provides  indication  that  all  preparations  necessary  for  conducting  Element  testing  are 
completed  or  the  reasons  why  they  are  not  completed.  The  package  also  identifies  any  risks 
and  concerns. 


PERFORMER; 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED; 
APPLICABLE  INSTRUCTION: 


Elements 

None 

None 

ETDR  Standard 


Activity:  BI-1 .5.8.3 

INSPECT  ELEMENT  TEST  PROCEDURES 

Element  test  procedures  are  inspected  to  verify  that  they  will  adequately  support  the 
element  test  plans  and  that  they  are  consistent  with  other  documentation.  Elements  choose 
inspection  participants  based  on  their  knowledge  of  the  Element  test  requirements  and  their 
experience  in  writing  and  evaluating  similar  test  plans.  The  inspection  is  conducted  in 
accordance  with  the  AEGIS  Software  Standard  for  Inspections,  including  the  collection  of 
metrics.  Element  and  System  QA  document  the  results.  Following  the  inspection,  the 
baseline  development  folder  is  updated,  if  necessary. 

RESPONSIBLE  ORGANIZATION:  Elements 

SUPPORTING  ORGANIZATION:  System  QA 

APPROVAL  REQUIRED:  None 


1  April  1996 
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APPLICABLE  INSTRUCTION:  Standard  for  Software 

Engineering  Inspections 


Activity:  BM  .5.8.4 

BUILD  SYSTEM  QA/ELEMENT-CONTROLLED  LOAD  FILES 


This  activity  begins  with  an  Element's  notice  to  System  QA  that  the  Element  is  ready 
to  build  a  System  QA/Element-controlled  load  file.  The  Element  provides  System  QA  with 
a  CPCR  closure  memo.  The  files  are  migrated  from  the  Element's  development  area  into 
the  System  QA  and  Element-controlled  directory.  System  QA  scans  the  files  collecting  the 
embedded  CPCR  numbers,  which  are  verified  against  the  closure  memo  and  ACCESS 
records.  System  QA  runs  VMS  Differences  and  verifies  that  all  changes  from  the  starting 
point  are  documented  by  a  valid  CPCR  number.  Upon  completion  of  these  steps,  the 
Element  and  System  QA  build  the  controlled  load  files.  Next,  System  QA  checks  patch  file 
records  against  the  approved  CPCR  lists  and  ACCESS  reports.  When  all  checks  prove  to 
be  satisfactory,  the  controlled  load  file  is  migrated  to  the  MEIT  jump  load. 


PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  System  QA 

APPROVAL  REQUIRED:  None 


APPLICABLE  INSTRUCTION:  Program  Development  and  Software  Quality  Assurance  in 

the  VAX  Environment,  QAI-200;  QAI-202:  Requirements  for 
Producing  Trial  QA  Load  Files  via  SYSBLD/43  or  SYSBLD/7 
in  the  VAX  Environment,  QAI-205:  Preparation  of  Changes 
to  Controlled  Source  Code  in  the  VAX  Environment,  QAI- 
212;  Patch  File  Coding  Standards  for  UYK-7  Computer 
Programs,  QAI-016;  UYK-43,  Naming  and  Formatting 
Conventions,  QAI-300 
CRB  Procedures 


Activity:  BI-1 .5.8.5 

UPDATE  ELEMENT  TEST  DISK  PACKS 

After  an  Element's  controlled  load  file  and  patch  file  changes  have  been  approved 
by  System  QA  and  Baseline  Management,  the  Element  instructs  MEIT,  via  a  migration  form, 
to  update  the  jump  load.  The  migration  form  contains  the  name  of  the  controlled  load  file, 
the  patch  file  PFP  order,  CPCR  numbers  incorporated,  a  short  description  of  the  change, 
and  any  program  limitations.  Upon  receipt  of  the  migration  form,  the  controlled  load  file  is 
migrated  to  the  jump  load  on  the  MEIT  disk  packs  at  the  ACC  and  the  ACSC.  MEIT 
provides  System  QA,  Baseline  Management,  and  each  Element  point  of  contact  with  copies 
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of  the  migration  form  and  the  PFP  order.  MEIT  also  updates  the  MEIT  logbooks  found  in 
the  ACC  and  ACSC  libraries  with  the  descriptions  of  any  changes  made  to  the  MEIT  disk 
packs  (e.g.,  listings,  PFP  order,  and  log  sheets). 


PERFORMER: 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


MEIT  (Baseline  Control) 

None 

None 

Maintaining  Jump  Load  on  MEIT  Disk  Packs,  MEIT  SOP- 
002;  Maintaining  Disk  Pack  Documentation,  MEIT-SOP-005 


Activity:  Bi-1 .5.8.6 

DEVELOP  SPECIAL  ELEMENT  ENGINEERING  TESTS 

Occasionally,  Elements  may  be  required  to  support  testing  that  is  not  associated  with 
baseline  deliveries.  These  tests  may  arise  from  the  need  to  support  operational  evaluations, 
engineering  evaluations,  equipment  development,  or  fleet  exercises.  As  the  test 
requirements  arise,  the  Elements  prepare  necessary  test  plans  and  test  procedures  as  well 
as  additional  data  collection  and  analysis  materials  as  required.  They  adapt  the  plans, 
procedures,  and  materials  from  existing  data,  where  feasible. 


PERFORMER: 

Elements 

SUPPORTING  ORGANIZATION: 

None 

APPROVAL  REQUIRED: 

None 

APPLICABLE  INSTRUCTION: 

None 

1  April  1996 


II-5-46 


NSV 


test  prep  status,  risks 


P583 

ETDR  package 

— ^ 

r 


NSWCDD/MP-93/85  Build  Implemei 


TDR  package 


V. 


P272 


ACCESS  database 


11-5-47 


1  April 


Build  Implementation 


CPCR  closure  memo 


system  QA  f1 1 e 


P311 


CPCR  folder 


CPCR  list,  CPCR  closure  memo 


421  I  system-level 
metrl cs 


584 


special  enginrg 
tests 


^  ! 


DIAGRAM  1.5.8.  PERFORM  SUPPORTING  ACTIVITIES  PROCESS 


P72 


ACCESS  database 


1  April  1996 


Build  Implementation 

Blank 


NSWCDD/MP-93/8S 


1  April  1996 


1I-5-48 


NSWCDD/MP-93/85 


Build  Implementation 


1 .5.9  PRODUCE  SYSTEM-LEVEL  TEST  PLAN  PROCESS 

The  Produce  System-Level  Test  Plan  Process  is  comprised  of  one  activity  as 
described  below.  Diagram  1.5.9  (Page  II-5-51)  is  a  data  flow  diagram  of  the  process 
and  its  constituent  activity. 


Activity:  BI-1 .5.9.1 

WRITE  SYSTEM-LEVEL  TEST  PLAN 

ST&E  evaluates  the  defined  combat  system  baseline  in  order  to  determine  specific 
test  requirements.  Test  requirements  are  derived  from  AEGIS  system-level  specifications 
using  applicable  Element  specifications  to  supplement  and  amplify  the  requirements,  new 
capabilities,  and  functional  upgrades  as  defined  during  the  System  Definition  Phase,  and 
from  other  computer  program  changes  resulting  from  the  Element  Definition  Phase.  Non-Mk 
7  upgrades  are  also  evaluated  to  ensure  adequate  combat  system  integration.  The  result 
of  the  test  requirements  identification  process  is  documented  by  ST&E  in  the  Test 
Requirements  List  and  Test  Requirements  Definition,  documents  that  constitute  the  Test 
Requirements  and  Acceptance  Criteria  of  the  system-level  test  plan. 

Once  the  test  requirements  are  defined,  analysis  is  performed  to  identify  test 
procedure  development  requirements.  Test  site  and  resource  requirements  are  evaluated, 
as  well  as  test  program  implementation  and  quality  assurance  and  configuration 
management  requirements.  ST&E  writes  the  system-level  test  plan  based  on  analyses,  test 
requirements,  and  evaluations. 

PERFORMER;  ST&E 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  System-Level  Test  Plan  Standard 
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